home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / CIS_GAME.ARJ / QANIM1.THD < prev    next >
Text File  |  1993-07-01  |  56KB  |  1,076 lines

  1. __________________________ Subj: Compiled Sprites __________________________
  2.  
  3. Fm: Mark Betz/GD SL 76605,2346                 # 109682 
  4. To: Mike Holt 100034,562 (X)                   Date: 17-Dec-91  13:08:37
  5.  
  6. Hi, Mike. Pointing SP to the video buffer and pushing the data is a neat
  7. idea. If both the PUSH and MOV methods use immediate data then there's no
  8. difference in speed, except that you have to set SP at the beginning of the
  9. block. I'd guess from the timing that, as far as the processor is concerned,
  10. PUSH is a MOV that always works with the same combination of registers as a
  11. destination. Sprite compiling takes the idea a step further. The compiler
  12. replaces the bitmapped data with a block of MOV instructions that use the
  13. pixel values as immediate data. So if you had this line in an image:
  14.  
  15.        07 08 23 51 5F 5E 4F 4F 3D 2C
  16.  
  17. The sprite compiler would turn it into this:
  18.  
  19.        MOV [BX], 0807
  20.        MOV [BX+2], 5123
  21.        MOV [BX+4], 5E5F
  22.        MOV [BX+6], 4F4F
  23.        MOV [BX+8], 2C3D
  24.  
  25. It would produce the actual opcodes, not the pnemonics as I've shown them
  26. above. To display this image you'd set the appropriate segreg to point to
  27. a000h (I think the current compiler uses DS), put the offset of the first
  28. pixel in BX, and make a far call to the first byte of the block. When John
  29. first hinted at the idea I was skeptical because I was sure the bitmaps would
  30. become too large. As it turned out the code generator was optimized so that
  31. in some cases the increase in size was minimal. The increase is speed is
  32. tremendous. There's code for all this in the lib (11) if you want to dive in.
  33. It's by no means reached it's full optimization yet. 
  34.                                                      --Mark
  35. ...........................................................................
  36.  
  37. Fm: Dan R Corritore 70243,1110                 # 188605 
  38. To: Bob Provencher 71621,2632 (X)              Date: 17-Jul-92  02:21:38
  39.  
  40. >>...what the even faster method you mentioned. (was)
  41. There isn't ONLY ONE faster method for doing animation. In fact, there are
  42. many. One really neat idea is the one of Compiled-Sprites (which was
  43. developed in this forum, although I don't know who by). The one I use is of a
  44. Count/Skip method. At each line, my routine loads a value which holds the
  45. amount of Count/Skip pairs in the line. Then, my routine loads the first
  46. pair, adds the SKIP value to the Screen Pointer, then does a REP MOVSB. Then
  47. it starts over until no more are left for the line, then goes to the next
  48. line,etc. I use a variation of this now, but I used to use that method often.
  49. Theres also another method which has the image in the Video Seg, and a 'Mask'
  50. in normal memory. You load the mask and write it to the 'Map Mask Register'
  51. or, if you are in EGA mode, the 'Bit Mask Register', then you transfer the
  52. image to the right spot on screen, 4 pixels (or 8, in EGA) at a time. For
  53. now, I've decided to use this strictly for animations which don't 'walk'
  54. around the screen (like a tree being blown around by wind, for example),
  55. because this particular method requires you to have it on a 4-pixel (or 8, in
  56. EGA) boundary. You can do things to hide that,though.
  57. Anyway, I've only done these methods in Assembly, because I doubt that you
  58. can get the same speed in higher-level languages.
  59.         _Dan 
  60. ...........................................................................
  61.  
  62. Fm: Mark Betz/GD SL 76605,2346                 # 188801 
  63. To: Dan R Corritore 70243,1110                 Date: 17-Jul-92  18:24:34
  64.  
  65. One note, Dan: compiling bitmaps wasn't developed in this forum. The topic
  66. came up here when John Dlugosz mentioned the idea. In my typical relevance to
  67. history I didn't think much of it <g>. Chris Lampton and David Stafford loved
  68. the idea, and jumped on it. I produced a timing program, while Chris and
  69. David produced compilers. David eventually produced a very fast compiler that
  70. only increased the bitmap size by a factor of 1.x, if I remember correctly.
  71. David also told Michael Abrash about the technique, and he mentioned it in a
  72. recent column for DDJ. At the time, David mentioned to us that this technique
  73. has been (is?) used in Windows, and is by no means new. 
  74.                                                         --Mark
  75. ...........................................................................
  76.  
  77. Fm: David Smith 71311,2334                     # 271279 
  78. To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 31-Dec-92  21:14:03
  79.  
  80. I'm using compiled bitmaps with great success. If the only reason that you
  81. want to clip the edges of the bitmaps is for the edges of the screen, you can
  82. do like I've done. Make the screen memory wider and taller than the visible
  83. area and just let the bitmaps hang off into the area that is not displayed.
  84. ........................................................................... 
  85.  
  86. Fm: Serge Mathieu 71035,2771                   # 273822 
  87. To: Mark Betz 76605,2346 (X)                   Date: 04-Jan-93  23:12:12
  88.  
  89. Mark,
  90.  
  91. As David Smith pointed out, the easiest way to clip compiled bitmaps is to
  92. << make the screen memory wider and taller than the visible area
  93. and just let the bitmaps hang off into the area that is not displayed.>>
  94.  
  95. Of course, if your bitmaps are too big or if the reserved area has to be kept
  96. to a minimum, you can cut them into small tiles and call the tiles that fit
  97. in this area.
  98.  
  99. I'm sending you some thoughts I had on compiled bitmaps; some might be
  100. good but most might just be inappropriate:
  101.  
  102. 1- Save your bitmaps on disk in compiled format so that you won't have to
  103. compile them at run time. It takes more space in memory and you cannot
  104. perform rotation or apply any modification to bitmap.
  105.  
  106. Bytes are represented by MOV ES:[DI+Offset],Color
  107.  
  108. In order to blit them anywhere in video ram, DI contains start address of
  109. bitmap; you set address before calling compiled bitmap:
  110.  
  111. MOV DI,Start_address
  112. CALL Bitmap
  113.  
  114. 2- You can blit to different screen widths or variable width ram buffers
  115. if BX or another register is added to DI at end of each horizontal line:
  116.  
  117. MOV ES:[DI+Offset],Color     (last pixel on this line)
  118. ADD DI,BX      (change line)
  119.  
  120. Offset is always calculated from beginning of each line, so most of the
  121. time, it will be less than 256 if your bitmaps do not exceed this width.
  122.  
  123. You set address and destination width before calling compiled bitmap:
  124.  
  125. MOV DI,Start_address
  126. MOV BX,Dest_Width
  127. CALL Bitmap
  128.  
  129. 3- Use compiled bitmaps in your ram buffer and use fast copy of unique
  130. 'dirty rectangles' to mode 13h or tweaked mode video ram. Buffer ram
  131. doesn't need to be wider or taller to allow clipping: blit compiled bitmap
  132. to another buffer the width and height of bitmap with preceding code and
  133. copy clipped area back to main ram buffer.  Of course, you have to fill
  134. second buffer with transparent color before blitting and check for
  135. transparency when copying it back to main buffer.
  136.  
  137. The idea is that clipping is less frequent than regular blitting and that
  138. extra processing is equal to the size of clipped bitmap. You can perform
  139. rotation or apply any modification to bitmap's copy before copying it back
  140. to main ram buffer.
  141.  
  142. 4- You can store your bitmaps in run-length encoded format. This way, you
  143. can clip them and eliminate the check for transparency. This is an
  144. alternative to compiled bitmaps.
  145.  
  146. ADD DI,Length_Trans_Color
  147. MOV CX,Length_Pixels
  148. REP MOVSB
  149. LOOP
  150.  
  151. _________________________ Subj: RLE Encoded Bitmaps _________________________
  152.  
  153. Fm: Chris Lampton [GAMPUB] 76711,301           # 322845 
  154. To: KGliner 70363,3672 (X)                     Date: 29-Mar-93  09:25:08
  155.  
  156. Any reason you can't use RLE-encoding on the bitmap? That way, you can not
  157. only skip entire _runs_ of transparent pixels in three or four instructions,
  158. but you can move entire runs of _non_transparent pixels in a tight loop with
  159. no transparency checking. The scheme I use in the Flights of Fantasy
  160. simulator is to break the bitmap into two types of runs: transparent runs
  161. (which consist of a single run-length byte with the high bit set) and
  162. nontransparent runs (which consist of a run-length byte _without_ the high
  163. bit set, followed by all the bytes in the run). This limits run-size to 128
  164. bytes, but that's more than adequate. The speed increase over a naive
  165. transparent blit was astonishing. 
  166. ...........................................................................
  167.  
  168. Fm: Chris Lampton [GAMPUB] 76711,301           # 323922 
  169. To: KGliner 70363,3672 (X)                     Date: 30-Mar-93  22:03:40
  170.  
  171. Can you afford to double the size of the bitmap? (Not knowing how big the
  172. bitmaps are, I don't know how many bytes that will cost you.) One idea I've
  173. been toying with -- I think we may have discussed something similar -- is to
  174. create a second byte map to accompany the pixel map. (Call it the "run map.")
  175. Each byte of the run map array would correspond to a pixel in the pixel map
  176. array. It contains the number of bytes remaining in the current transparent
  177. or non-transparent run. For instance, if the pixel map looked like this:
  178.  
  179. 117,39,251,8,17,0,0,0,0,0,0,0,0,0,201,125,99,148
  180.  
  181. then the corresponding run map would look like this:
  182.  
  183. 5,4,3,2,1,9,8,7,6,5,4,3,2,1,4,3,2,1
  184.  
  185. There would be no compression, so you could easily locate a random position
  186. in either map. By checking the value in the run map for that position, you
  187. would know how many pixels remain after that point in the current transparent
  188. or nontransparent run. By checking the pixel value, you would know if the
  189. current run were transparent (zero pixel) or nontransparent (nonzero pixel).
  190. You could then scale the run length, skip that distance (for a transparent
  191. run) or initialize the tightest loop you can to grab the nontransparent
  192. values (at scaled distances from one another) that remain in the run, with no
  193. need for transparency checking.
  194.  
  195. Whether you actually _want_ to do that, of course, depends on how much extra
  196. memory it would cost you to double the bitmap size and whether you could get
  197. enough speed increase to be worth it. (And whether it's worth the hassle of
  198. rewriting the code. <g>)
  199. ...........................................................................
  200.  
  201. Fm: Epic MegaGames 70451,633                   # 326292 
  202. To: KGliner 70363,3672 (X)                     Date: 03-Apr-93  20:54:54
  203.  
  204. Kevin,  store your bitmaps using RLE compression -- you'll save tons of space
  205. and drawing time too.  For example,  if you're going to do a bit by bit
  206. move.. 
  207.  
  208.    lodsw ax                  ;Get byte (al) & run length (ah) from sprite
  209.                              ;bitmap
  210.    stosb al                  ;store it on screen
  211.    add dx,ah                 ;skip over rle (0=no run length, etc)
  212.    loop
  213.  
  214. And if you're really optimizing,  you'll do this in CHAIN4 mode by first
  215. moving all 4 planes together from video memory (ultra fast), then by going
  216. through each of the four individual planes and moving lone pixels from system
  217. memory. 
  218.                       Tim
  219.                       (The art of bit blitting)
  220. ...........................................................................
  221.  
  222. Fm: KGliner 70363,3672                         # 326490 
  223. To: Epic MegaGames 70451,633                   Date: 04-Apr-93  03:08:33
  224.  
  225. Tim-  I suspect you missed the context of the original message on
  226. transparency. The problem involved scaling through scanlines of pixels at
  227. variable rates (eg. sometimes 3.76 pixels at a time, sometimes .23 pixels,
  228. etc), and there was also clipping at both ends.  All of it was being done in
  229. RAM-- none of it to the video screen.  And the loops were all unrolled too.
  230. In the end I felt the complexity of applying RLE encoding to indivdual pixel
  231. runs (that didn't even end on single pixel boundaries) would take too much
  232. time to implement under my schedule (and with questionable benefits since
  233. most of the bitmaps were fairly complex).
  234.  
  235.     Just the same, thanks for the reminder about how RLE works...
  236.  
  237.     Kevin
  238. __________________________ Subj: Animation Speed __________________________
  239.  
  240. Fm: Dan Corritore 70243,1110                   # 324878 
  241. To: Bret Dixon 100117,3633 (X)                 Date: 01-Apr-93  16:17:34
  242.  
  243. Ok, first off, there are a few ways to do the sprites. (1)You can have them
  244. stored in memory as 1 byte per pixel, or (2)you can have 4 runs of memory --
  245. each run consisting of 'masks' that you use to write to a specific color
  246. plane (R,G,B,I). (3) You could have the sprites stored in video memory. And
  247. (4)then you can have them saved as 8 copies, each one being for every 8th
  248. pixel. 1. Using the first approach , you'd use write mode 2, and write the
  249. sprites vertically, from left to right. This would make the number of OUT's
  250. to the ports equal to the width of the sprite. Also, although it is possible
  251. to do it 2 pixels per byte, it's easier to do 1 pixel per byte. Speed is
  252. moderate. 2. Using the second approach(4 runs-1 for each color plane), you'd
  253. use write mode 0, and you'd start out each run with a different color plane
  254. selected (R,G,B,I).. you'd then write 8 bits at a time to the display-- when
  255. all 4 runs are finished, the colors would build the sprite. Using this method
  256. would result in the most efficient use of memory, but it will make it tough
  257. to write to anything other than byte-boundaries.(unless you have 8 copies,
  258. each offset by 1 pixel) Speed is very good, provided that you are writing to
  259. byte-boundaries. 3. You can have the sprites stored in (preferrably hidden)
  260. video memory. You'd then use write mode 1 to transfer the sprite to the
  261. location of your preference, 8 pixels at a time. This is pretty much the same
  262. as using #2 approach. You will also need to have more copies stored in video
  263. Ram to write to something other than a byte boundary. Speed is very good.
  264. 4.Using the last approach(having 8 copies), you'd use write mode 2, and you'd
  265. write, possibly using REP MOVSB, the colors for every 8th pixel, by selecting
  266. at the beginning of each copy a specific bit mask for the current spot. One
  267. Note, though--using the last approach, you'd have to have 1 byte per pixel,
  268. otherwise the REP MOVSB wouldn't be allowed. Speed is good. The above
  269. techniques can be changed to allow transparency by doing the following:
  270.  
  271. 1.for the first method, you'd just need to have a transparent color(usually
  272. 0) stored for each non-writeable pixel
  273. 2. for the second method, you'd need to have a 5th run of 8 pixels per byte,
  274. which contains 1's for writeable pixels, and 0's for non-writeable pixels.
  275. While doing the runs, you'd need to set the bit mask register for each write
  276. using the 5th run's values.
  277. 3. you'd use the same as (2), by having a 5th run which describes 'visibile'
  278. and 'non-visible' pixels, and setting the bit mask register before
  279. transferring video memory to video memory.
  280. 4.you'd use the same approach for (1)
  281.  
  282. I'd recommend that you use either 1,3, or 4. Technique 2 could be used if you
  283. don't have enough video memory to spare, though.
  284. That about covers the techniques I've seen/used. There are also techniques in
  285. which you have compressed sprites or run-length-encoding,etc., but they are
  286. usually a variation of one of the above techniques (and usually technique 1).
  287. Re:Overlapping-- just have some sort of ordering routine that will write the
  288. sprites that are behind others first. The best way to do that would be to
  289. look at where their feet are..
  290.         Whew! I hope I got that right!
  291.         _Dan
  292. ...........................................................................
  293.  
  294. Fm: rod lentz 71163,57                         # 324955 
  295. To: Dan Corritore 70243,1110 (X)               Date: 01-Apr-93  18:58:07
  296.  
  297.     Bret -
  298.     Dan's answers are correct if your problem is simply the overhead
  299. per frame, which you're trying to reduce.  It doesn't answer the
  300. other possible reading of your question, which would be that you're
  301. having trouble keeping a constant frame rate regardless of scene
  302. complexity.
  303.     To deal with this, you'll have to base your animation timings on
  304. one of the pc's built-in clocks/timers.  This is usually done off
  305. system timer 0, which is used for system clock's "ticks since
  306. midnight".
  307.     Using this, there are two ways to go.  The first simply shoots
  308. for a constant frame rate, by waiting in a loop, watching the timer,
  309. to ensure a constant time from the beginning of one frame to the
  310. beginning of the next.  The second method is to try to get as much
  311. animation into the available time.  This is done by finding out how
  312. long the previous frame took to image, and then scale all motion
  313. for the next frame by that number.
  314.     This also nicely handles differences in machine speeds.  I'm
  315. amazed at the number of games (mostyly PD/FW/SW) that don't do this,
  316. and so are unplayable on my 486/33 <argh!>.
  317.  
  318.         - Rod
  319. ...........................................................................
  320.  
  321. Fm: Dan Corritore 70243,1110                   # 325172 
  322. To: rod lentz 71163,57 (X)                     Date: 02-Apr-93  00:01:43
  323.  
  324. On regards of the timing issue, if he's using page-flipping, then he'll
  325. already have the basic timers-the screen retraces.. these aren't the fastest
  326. things to use, but they do keep the frame rate at a constant rate. Using one
  327. of the 2 timers (well, on AT computers and up, he can use the secondary CMOS
  328. timer) is another way to go too. Although I've only used the CMOS timer,
  329. there's also the system timer, which can give you more precision in timing
  330. (the reason I don't use it is because I have a music driver running on the
  331. timer interrupt). There are so many ways to do things on PC's... it makes
  332. some people go nuts! <g> 
  333.         _Dan  
  334. ...........................................................................
  335.  
  336. Fm: rod lentz 71163,57                         # 325237 
  337. To: Dan Corritore 70243,1110 (X)               Date: 02-Apr-93  02:23:11
  338.  
  339.     Yep, the screen retraces will work, too - assuming you can always
  340. generate a fresh one as fast as the card needs 'em.  If not, you'd
  341. always be delaying [unknown ?] multiples of the refresh rate.  Also,
  342. due to differences in refresh rates between different adapters &
  343. monitors, this still won't be tying you to an absolute rate.  I prefer
  344. to go off a "real" clock, myself.
  345.     BTW, if you define your pages to always start on 256-byte
  346. boundaries, you can safely flip pages without a retrace wait.
  347.     I've usually used the PIT's for clocking, but with fewer and
  348. fewer pc/xt's out there/suitable for my apps, I've been using the
  349. CMOS timer more.  It's a heck of a lot easier, IMHO.  Also, having
  350. a music driver running off the PIT shouldn't preclude using it for
  351. other timing, as well.  In fact, I rarely use the PIT's interrupt
  352. for this kind of delay; I usually just read the timer's counter.
  353.     As you say, so many ways to do it...  the trouble is finding
  354. one that's always "best" on all systems <g>.
  355.  
  356.         - Rod
  357. ...........................................................................
  358.  
  359. Fm: Dan Corritore 70243,1110                   # 325420 
  360. To: rod lentz 71163,57 (X)                     Date: 02-Apr-93  14:09:53
  361.  
  362. It's true that sometimes the page-flipping rate could change somewhat, but
  363. I'd doubt that it would be too often that it would. And if you take a look at
  364. a lot of games out there, you'll notice that they work at an acceptable speed
  365. for _most_ of the time, until there's a lot of animation going on, and then
  366. it slows down.. it's bearable, at least, to me. But basing when to do the
  367. next page-flip according to the previous drawing/flipping time would be
  368. silly, IMHO. But games and stuff which don't use page-flipping practically
  369. require to have things going at a constant rate, possibly by looking at a
  370. timer.. but I haven't seen/heard of too many that change their drawing rates
  371. according to how much animation is going on in the screen..
  372.         And about the different refresh rates-- it was my understanding that
  373. a card of a particular type (like VGA) should be about the same rate for all
  374. those cards. I think for VGA it's 70Hz or something? Or possibly 60Hz?
  375. <<Also, having the music driver running off the PIT shouldn't preclude using
  376. it for other timing, as well.>>
  377.         Well, it will if you don't know the rate at which the timer interrupt
  378. is called(and have no way of finding out)!! That's what my problem is--not
  379. knowing the rate at which it is called.. it would screw up even microsecond
  380. timing, at least, that's what I think Mark Betz said. (creator of the HTimer
  381. class)
  382.         So, I'm using the CMOS timer.. and yes, it is easier to use. But it
  383. is a possibility that the batteries could be dying.. leading to incorrect
  384. timing, yes? Or is that only while the computer is off?
  385.         _Dan  
  386. ...........................................................................
  387.  
  388. Fm: Randy @ Safari 71165,3600                  # 325804 
  389. To: Dan Corritore 70243,1110                   Date: 03-Apr-93  01:57:13
  390.  
  391. Apogee's FAST uses variable frame rate timing. Which gives an appearance of
  392. the same frame rate on any speed machine. This is normally why Apogee FAST
  393. games don't have stupendous sound or music,  because FAST takes one of the
  394. timers to manage variable rate animation.
  395.  
  396. I prefer the fixed frame rate cap method. People with slow machines are aware
  397. that they have slow machines. ALL games run slow on slow machines (or you
  398. play Apogee's no music FAST games). 
  399. Randy 
  400. ...........................................................................
  401.  
  402. Fm: rod lentz 71163,57                         # 325879 
  403. To: Randy @ Safari 71165,3600 (X)              Date: 03-Apr-93  06:26:38
  404.  
  405.     I've used the variable frame rate timing very successfully in some
  406. animation [not games]; product intro screens, &c.  Worked very nice
  407. for a bit that needed to run on cga/ega/vga from pc/xt's to the top
  408. of the line (386 at the time).  Very well, considering this involved
  409. a [simulated] rotating, scalable, texture-mapped sphere; better than
  410. any other attempt I've seen.  Sure, it would get kinda jerky on a
  411. low-end machine with a high-res display, but always at a constant
  412. rate.
  413.     Of course, if you have other stuf to do in the background, it's
  414. pretty much out.
  415.     All in all, depends on the application.
  416.     Randy - I presume Apogee's FAST is a library they have; which
  417. games use it ?
  418.     BTW, the CMOS battery should only affect it when the machine's
  419. off; so, relative timing like we're talking about should always be
  420. fine.
  421.         - Rod
  422. ...........................................................................
  423.  
  424. Fm: Randy @ Safari 71165,3600                  # 326010 
  425. To: rod lentz 71163,57 (X)                     Date: 03-Apr-93  12:49:01
  426.  
  427. FAST is used in Pharoahs Tomb (oooh) and Monster Bash (Not yet released). It
  428. was written by Gerald Lindsley (sp). Also, some SoftDisk games were done with
  429. it like ScubaVenture.
  430.  
  431. It's not bad all in all but I still prefer the resource file & hand written
  432. engine approach.
  433.  
  434. Randy 
  435. ...........................................................................
  436.  
  437. Fm: rod lentz 71163,57                         # 326521 
  438. To: Randy @ Safari 71165,3600 (X)              Date: 04-Apr-93  04:56:51
  439.  
  440.     Pharaoh's Tomb - ah, now I remember the mention.  I was kinda torn
  441. on that one; not a bad game, but the collision detection was horrible !
  442. I think they mentioned that was related to FAST in the doc's; they
  443. put a simple bounding box around everything, and if they overlap,
  444. then... you die !  The big problem was, the bounding boxes were much
  445. too liberal, and you were killed by objects that, as far as the
  446. display was concerned, weren't very close.  Not that that's a
  447. requirement of the variable-action-per-frame technique that we've
  448. been discussing.
  449.  
  450.     As far as "resource file & hand written engine", I'm not entirely
  451. sure what you mean.  Personally, I prefer a "generic" engine, that
  452. can be dropped into any app that fits; of course, that's tough to
  453. do in state of the art games, and you often have to resort to custom
  454. code for many parts.
  455.  
  456.         - Rod
  457. ...........................................................................
  458.  
  459. Fm: Bret Dixon 100117,3633                     # 326588 
  460. To: rod lentz 71163,57                         Date: 04-Apr-93  10:24:37
  461.  
  462. Dan/Rod/Randy:
  463.  
  464. Bret again! Thanks for all the info.
  465. First of all, Dan, thanks for the animation method info. I am currently using
  466. your Method 1 (Write Mode 2, 1 memory byte per pixel). I am actually using 2
  467. bytes per pixel but it is the same method. As you say, this has moderate
  468. speed. I have found it is inadequate on slower
  469. machines. Your Method 2 (write mode 0, writing the 4 colour planes) sounds
  470. the best to me, although you did not advise the use of this method. You said
  471. it is a problem writing short of a byte boundery. Do you think it would make
  472. much difference to write to the boundery as over-kill just for programming
  473. ease? Or would this impact performance?
  474. Your Method 3 (Write mode 1, using Video memory) does not seem to be
  475. feasible. This may be due to my limited understanding. If you use Video
  476. memory, then you are limited to the Read/Write modes you have set. Write mode
  477. 1 is very limiting, and I don't understand how you can manipulate pixels in
  478. video memory short of using the other methods you have suggested. In other
  479. words, you seem to need one of the other methods to achieve Method 3. Your
  480. Method 4 (Write mode 2, and 8 copies in memory), seems to be an unnecessary
  481. exploitation of memory for the same performance you can get from Method 1. I
  482. am explaining all this so that you can correct me if I have missed the point.
  483. Anyway, my vote is for Method 2. If I'm wrong, please try and talk some sense
  484. into me! 
  485. As for timing, Dan, Rod and Randy, I am currently reprogramming the System
  486. Timer Channel 0 to pulse more frequently. This is because I found that 1
  487. animation frame takes less than 18.2 of a second (the default programmed
  488. pulse rate). I changed it to an arbitrary 400 pulses per second and found my
  489. frame takes about 100 ticks (I am using the counter at 0040:006C). I needed
  490. to slow the frame down to just over 200 ticks so that animation is not too
  491. fast. But this is on a 386 33mhz.
  492. Is this approach any good? What about using the CMOS time (I have never heard
  493. of this approach). How does it work?
  494.  
  495. Also, I have found that if I deactivate the Turbo, my animation starts to
  496. crawl across the screen. But in games like Gods by Bitmap Bros. deactivating
  497. the Turbo has no apparent effect. What is going on? Is it possible to
  498. deactivate the Turbo?
  499.  
  500. Any further info will be gratefully accepted, and thanks for all your help so
  501. far!
  502.  
  503. Bret.
  504. ...........................................................................
  505.  
  506. Fm: Randy @ Safari 71165,3600                  # 326733 
  507. To: rod lentz 71163,57                         Date: 04-Apr-93  15:06:25
  508.  
  509. What I was referring to was the ability to create a "standard" game resource
  510. file (sounds,maps, graphics) and utilize that file with any engine you write
  511. as opposed to the FAST method where you develop the maps & chars in FAST, it
  512. compiles them, then it gives you a game framework to build on.
  513.  
  514. The problem with FAST is that all FAST games look like FAST games,  you know
  515. what I mean? The character slides to a stop instead of stopping immediately,
  516. big blocky graphics, no multi-planar scrolling backdrops (it uses PCX files
  517. for the solid backdrop and then you can lay foreground tiles on top).
  518.  
  519. Randy 
  520. ...........................................................................
  521.  
  522. Fm: Dan Corritore 70243,1110                   # 327018 
  523. To: Bret Dixon 100117,3633 (X)                 Date: 04-Apr-93  21:47:29
  524.  
  525. About using method #2.. I advised against it because of the fact that it
  526. would be a bit tougher to write to anything but a byte-boundary.. but
  527. actually, it shouldn't be too hard to adjust for this.. you just need to
  528. shift bits to the right, and allow for overflowing to the next byte, etc..
  529. it's speed won't really change by much, as far as I'd be able to tell. But
  530. when you add transparency to it, then your speed will start to decrease,
  531. because you must do an OUT before each write (and also shift if on a non-byte
  532. boundary)... actually, the speed shouldn't be too too bad (although you do 4
  533. OUT's per every 8 pixels)..
  534.  
  535. <<Your Method 3 (Write mode 1, using Video memory) does not seem to be
  536. feasible. This may be due to my limited understanding. If you use Video
  537. memory, then you are limited to the Read/Write modes you have set.>>
  538.  
  539. Using video memory, you can use any read mode/write mode you darn well
  540. want! Using method 3, you draw the sprites into a hidden( and unused) portion
  541. of video memory on startup, then draw those sprites from then on using Write
  542. mode 1. <<Your Method 4 (Write mode 2, and 8 copies in memory), seems to be
  543. an unnecessary exploitation of memory for the same performance you can get
  544. from Method 1..>>
  545.         About the memory requirements--actually, it's the same size as method
  546. 1... the 8 copies aren't really 'copies', but parts of the sprite split up..
  547. I mean, every copy holds every 8th pixel in it. About the speed-- you can use
  548. REP MOVSB's with it, if you play your cards right (either have
  549. non-transparent figures or run-length-encoding (RLE) compression).. also,
  550. only 8 OUT's are necessary
  551.         Now.. let me revise my view on the others.. Method 1 is the easiest,
  552. and is portable (but who cares about portability!?? <g>). It's speed is 'good
  553. enough', but not for everybody. I have a RLE-like implementation of Method 1
  554. which seems to work pretty darn fast, though. Method 2-- easy to use, if you
  555. are going for byte-boundaries only. And about using byte boundaries-- that's
  556. not too limiting, just remember to have some animation to make it look as
  557. though it's not using byte boundaries. Method 2 isn't that bad, though, and I
  558. don't know why I didn't recommend it, but I'd guess I said that because I'm a
  559. 256-color 'tweaked' mode programmer now, and don't like 16-color anymore! <g>
  560. Method 3-- well, method 2 can replace it, but it requires more writes (method
  561. 2- 8 pixels= 4 writes, method 3- 8 pixels= 1 read, 1 write).. and remember,
  562. the less you access video ram the better! But I've never used video ram-based
  563. sprites myself.. partly because they are limiting in a way(byte-boundary
  564. only.. unless multiple copies). I'd say to use write mode 1 for
  565. drawing/saving backgrounds or whatnot, since backgrounds don't change.. it
  566. would also be good for 'erasing' sprites. So I'd guess the order of speed for
  567. these would be(in best to worst order) : 4( 8 copies),3 (vram to vram),2(4
  568. copies),1(single copy) . If it was up to me, I'd use method 4 (for ease of
  569. use/speed), or method 1 (for ease of use).. and if worst came to worst method
  570. 2 (a bit too complicated). 
  571.         Questions? :)
  572.         _Dan  
  573. ...........................................................................
  574.  
  575. Fm: rod lentz 71163,57                         # 327100 
  576. To: Randy @ Safari 71165,3600 (X)              Date: 04-Apr-93  23:44:11
  577.  
  578.     I know what you mean about all FAST games looking the same.
  579. However, having a generic engine also has its appeal.  The problem
  580. is coming up with a complete and flexible enough design that you
  581. can handle everything; and within the constraints of current hardware.
  582.     And of course, I'm also a programmer <g>; I don't just want to
  583. use a CASE tool.
  584.     No perfect solution, I guess :).
  585.  
  586.     About using the system timer - I don't quite understand why
  587. everybody seems to reprogram it, and use the interrupt.  Sure, that's
  588. great if you need something in the background, but for foreground
  589. tasks I find it easier to just read the current value from the chip.
  590. For longer delays, combine this with the system's tick counter.
  591. Anybody care to shed some light for me ?
  592.  
  593.         - Rod
  594.  
  595. ...........................................................................
  596.  
  597. Fm: Ed. Mueller 70441,3720                     # 343766 
  598. To: ALL                                        Date: 28-Apr-93  22:12:24
  599.  
  600. Let's talk hypothetically.  Lets say I have a character which has 100
  601. distinct frames of animation whose sizes vary from roughly 50x50 to as big as
  602. 100x50. All together we're talking roughly .5 MB worth of images (256 color
  603. mode). Naturally, I'd need access to each image quickly since we're doing
  604. heavy duty animation.  The 1 MB limit on DOS does not leave much room for any
  605. program to control the images.  Also, I'd be using compiled sprites such that
  606. each image would have to reside in the 1 MB address space so that it could be
  607. called to draw the image.  What are my options and what are the tradeoffs? 
  608. My ideas are as follows:
  609.  
  610.  - Use some type of DOS extender or XMS.  Problem is each sprite must be
  611.    copied to conventional RAM to be executed (right?).  Would that overhead
  612.    be too much?
  613.  - Use a 32-bit compiler.  Not such a great choice because I'd be using
  614.    Borland C++ 3.1.  Is there anyway for it to generate 32-bit code?
  615.  
  616. Let me hear your ideas.  Thanks again.
  617. ...........................................................................
  618.  
  619. Fm: Maxx 71102,1124                            # 344034 
  620. To: Ed. Mueller 70441,3720 (X)                 Date: 29-Apr-93  08:53:53
  621.  
  622. I'm not sure about BC3.1 (I know it has an option for 286 codes and 386
  623. codes) I do know that Watcom C will do 32 bit , but it's a little pricy..
  624.  
  625. Just as a hypothetical suggestion, how about having this massive sprite be
  626. compressed in memory, then expanded when drawn? (Using a fast decompressor of
  627. course)  Just an idea..
  628. ...........................................................................
  629.  
  630. Fm: E. Pinnell [CyberSim] 70031,435            # 344064 
  631. To: Ed. Mueller 70441,3720 (X)                 Date: 29-Apr-93  10:07:54
  632.  
  633. Ed,
  634.  
  635.    Get a compiler that creates 32 bit DPMI compliant code.  If you go for a
  636. DOS extender (a la Phar Lap), this will work too but they cost more (some
  637. require royalties).
  638.  
  639. Eric Pinnell
  640. ...........................................................................
  641.  
  642. Fm: Mark 'SAM' Baker 100025,444                # 344148 
  643. To: Ed. Mueller 70441,3720 (X)                 Date: 29-Apr-93  12:49:13
  644.  
  645. Don't store the entirety of each frame; only the differences from the last
  646. frame displayed. Then only the first frame needs to be stored in a full state.
  647. This will not only reduce the overhead required for storing frames 2 to 100;
  648. but can also speed up the drawing of the frame.
  649.  
  650.                                 Mark
  651. ...........................................................................
  652.   
  653. Fm: VOR Technologies Inc 71333,134             # 344220 
  654. To: Ed. Mueller 70441,3720 (X)                 Date: 29-Apr-93  14:53:30
  655.  
  656. Ed,
  657.  
  658. Are the frames your storing transitions from one another? If so you can come
  659. up with a simple diffing agolrythm that will store the changes from frame to
  660. frame and then use a piece of code that will just plot the appropriate
  661. changes pixels between each frame. This offers very fast and smooth
  662. animation. And wil decrease the overall size a lot of the transitions are
  663. gradual as in a normal animation. 
  664.  
  665. Chris Eisnaugle Vor Technologies Inc.
  666. ...........................................................................
  667.  
  668. Fm: Steve Salter 71732,3126                    # 344754 
  669. To: VOR Technologies Inc 71333,134 (X)         Date: 30-Apr-93  07:29:53
  670.  
  671. |Are the frames your storing transitions from one another? If so you can come
  672. up |with a simple diffing agolrythm that will store the changes from frame to
  673. frame |and then use a piece of code that will just plot the appropriate
  674. changes pixels |between each frame. This offers very fast and smooth
  675. animation. And wil |decrease the overall size a lot of the transitions are
  676. gradual as in a normal |animation. | |Chris Eisnaugle Vor Technologies Inc.
  677.  
  678. I think I missed the start of this thread...are you talking about animating
  679. sprites or background bitmaps? This sounds very intriguing.
  680.  
  681. Steve
  682.  
  683. __________________________ Subj: Animation Timing __________________________
  684.  
  685. Fm: Cameron Grant 100031,2265                  # 146200 
  686. To: Karl R Corritore 70243,1110 (X)            Date: 20-Mar-92  16:27:45
  687.  
  688. In my game DOMINATION, (the current version 1.2, unreleased as yet...) I'm
  689. using the vertical retrace irq to run some 8 layer 70Hz paralax scrolling
  690. stars and colour cycling in the background...It looks pretty impressive!!!
  691. I just took a look in kliewer's book (or whatever his name is <g>) at the
  692. vertirq2 source, and then translated the bits I needed into BASM in TP6!  Was
  693. extremely surprised when it worked perfectly first time tho'!
  694.  
  695. Dunno what happened to that response...(!)
  696. I didn't find it too difficult to write a vertical retrace int handler, I
  697. just look in kliewer's book at the VERTIRQ2.ASM source code, and appropriated
  698. bits of it...
  699. ...........................................................................
  700.  
  701. Fm: Activision/Infocom 76004,2122              # 188032 
  702. To: Mark Betz/GD SL 76605,2346 (X)             Date: 15-Jul-92  13:12:08
  703.  
  704. We just shipped LGOP2, a very complex game that has alot of tasks tied to the
  705. timer interrupt.  Like a 8KHz task that pumps out 4 channel digital audio and
  706. forks to:
  707.  
  708. 1. A Cursor and mouse/keyboard/joystick task.
  709. 2. The audio decompression task.
  710. 3. The Midi Task.
  711. 4. The clock tasks.
  712. 5. Fifo tasks for various devices.
  713. 6. The 18.2Hz system task.
  714.  
  715. It also had a Mac-style memory manager that moved stuff around.
  716.  
  717. Would up renting a Periscope IV just to fix problems.
  718.  
  719. Even after all that, I've discovered...
  720.  
  721. 1. Errant sound cards (1/1000) can take a very long time to acknowledge a
  722. write to a hardware register.
  723.  
  724. 2. Some BIOS/PC systems actually mess up the MOVE.SW direction flags.  No
  725. lie. 
  726. 3. There are non-register compatable VGA cards out there.
  727.  
  728. 4. QEMM and other 386 managers slow down interrupts alot.
  729.  
  730. 5. Animation optimization is great, but you'll spend all of your time writing
  731. to video memory anyway .... it's very slow.
  732.  
  733. Not fun, but instructional...
  734. ...........................................................................
  735.  
  736. Fm: Serge Mathieu 71035,2771                   # 193923 
  737. To: Dan R Corritore 70243,1110 (X)             Date: 31-Jul-92  15:53:53
  738.  
  739. Dan,
  740.  
  741. How do you do your timing for animation? I have theses solutions:
  742.  
  743. 1- Hook yourself on vertical refresh of video card for 70 ticks/sec 2- Hook
  744. yourself on INT 08 for 18 ticks/sec 3- Hook yourself to sound driver to about
  745. 10,000 ticks/sec
  746.  
  747. ......???
  748.  
  749. Serge Mathieu
  750. ...........................................................................
  751.  
  752. Fm: Dan R Corritore 70243,1110                 # 193965 
  753. To: Serge Mathieu 71035,2771 (X)               Date: 31-Jul-92  17:03:29
  754.  
  755. Well, the fact is, I was going to try each one of the ideas you tried (except
  756. #3, which I never heard of doing) . Hooking yourself into the vertical
  757. interrupt is a great idea, but the only thing is, not every computer will
  758. support this.
  759. The timer interrupt is a possibility, and it can be programmed to run at a
  760. certain pace, too. I was going to run the timer interrupt at 70 times per
  761. second, and have the timer routine check a variable to see if I was done
  762. writing to a page, and then flip pages at each vertical interrupt. This would
  763. also require the animation drawing routine to check this variable to see if I
  764. changed pages yet before it draws the screen(which ends up in a Loop
  765. anyways)..And since there is a _CLI_ instruction, there is the possibility
  766. that the timer could be knocked off a bit.. And, since some sound drivers and
  767. stuff run off the timer interrupt, it becomes less desirable to do this.
  768.  
  769. I do my drawing onto a 'hidden' page, so that it doesn't need to be
  770. timed..its just the page flipping that needs to be timed. So far, I've been
  771. doing the combination of waiting for Vretrace, then changing pages, then
  772. waiting for a Non-retrace. Then I do some processing, and erase and write the
  773. new sprites, then flip pages again, and so on..
  774.  
  775. So far, it works good..but sometimes, there is a slight flash in the screen,
  776. so I know the timing is off a bit, but its bearable for now..
  777.  
  778.         _Dan 
  779. ...........................................................................
  780.  
  781. Fm: Randy @ Safari 71165,3600                  # 344049 
  782. To: Dan Corritore 70243,1110 (X)               Date: 29-Apr-93  09:32:45
  783.  
  784. re: Space Chase
  785.  
  786. ->development system
  787.  
  788. the new system was being written while Game 1 was being done, there just was
  789. not time to redo all the levels.. Games II and III are done with the
  790. development system and are much more vivid with walk-behind trees, flowing
  791. grass, c-thru chain-link fences, etc...
  792.  
  793. ->my butt
  794.  
  795. Maybe _your_ code can only do 50fps ;) No really, it's possible on a 12Mhz
  796. 80386 with a 16-bit video card to get 90-105 fps using the FAST method with
  797. no parallax backgrounds. 8-bit cards will usually do 58-70 fps depending on
  798. the card and machine but the engine knows which one it's using and makes the
  799. necessary changes to run faster. Heck, it does 157fps on a 33Mhz 386 with
  800. 16-bit video card.. that's 160 scan lines, not 200 (at 200 it's 131 fps on a
  801. 386-33 w/16bit card) 
  802.  
  803. ->good luck <on Sonic>
  804.  
  805. wouldn't that be an incredible undertaking.. the only drawback is that it
  806. wouldn't have the multiple scrolling backdrops like Sonic.. That's just not
  807. possible on low-end machines at high speeds. I don;t think we'll be doing
  808. Sonic anytime soon..
  809.  
  810. Randy 
  811. ...........................................................................
  812.  
  813. Fm: Dan Corritore 70243,1110                   # 344168 
  814. To: Randy @ Safari 71165,3600 (X)              Date: 29-Apr-93  13:14:31
  815.  
  816. Well, your new system sounds pretty good.. I hope you're going to use that
  817. for your first game!
  818.  
  819. <<Maybe _your_ code can only do 50fps ;) No really, it's possible on a 12Mhz
  820. 80386 with a 16-bit video card to get 90-105 fps using the FAST method with
  821. no parallax backgrounds. 8-bit cards will usually do 58-70 fps depending on
  822. the card and machine but the engine knows which one it's using and makes the
  823. necessary changes to run faster. Heck, it does 157fps on a 33Mhz 386 with
  824. 16-bit video card.. that's 160 scan lines, not 200 (at 200 it's 131 fps on a
  825. 386-33 w/16bit card)>> 
  826.  
  827. The fact is, you can't go faster than the scanning rate of the video card and
  828. monitor.. currently, there are no 105 HZ monitors _or_ video cards out there
  829. (unless I'm missing something.. perhaps that new XGA card?<g>) Actually, it
  830. is possible to write to the video adapter at 100+ fps, it's just the user
  831. will only see maybe half of that. It's no use to go any faster than the scan
  832. rate of the cards/monitors, if that's what you are doing.(which you must be
  833. doing if you're getting reports of 100+ fps!!)
  834.  
  835. Oh, no parallax scrolling on Sonic? Sure, I can see doing the Sega Game Gear
  836. version of Sonic.. no problem! :)
  837.  
  838.         _Dan  
  839. ...........................................................................
  840.  
  841. Fm: Randy @ Safari 71165,3600                  # 344195 
  842. To: Dan Corritore 70243,1110 (X)               Date: 29-Apr-93  13:51:40
  843.  
  844. True.. you cannot update faster than the scan rate.. the point is to get the
  845. game as fast as possible, then slow it down artificially to achieve a
  846. standard frame rate... I think 40fps is more than enough
  847.  
  848. Randy 
  849.  
  850. _____________________ Subj: Compiled Animation Sequence _____________________
  851.  
  852. Fm: Mark Betz/GD SL 76605,2346                 # 216698 
  853. To: all                                        Date: 23-Sep-92  17:30:55
  854.  
  855. Hi, guys. I want to poll you for some thoughts on the design of an special
  856. animation engine. If you've been through the libs you may be familiar with
  857. the idea of bitmap compilation, which was resurrected here sometime back. In
  858. case you haven't, I'll briefly recap: The standard method of displaying a
  859. bitmap involves a loop of instructions to move bytes or words from one place
  860. in memory to another place in display memory. As we all know, one of the
  861. standard techniques of optimization is loop unrolling. Compiled bitmaps are
  862. the ultimate unrolled loop. When a bitmap is compiled the image data is
  863. scanned, and the compiler outputs a series of opcodes with the image bytes as
  864. immediate data. For example, if a bitmap contains the bytes 223 227 226, the
  865. compiler creates something that looks like this  MOV ES:[110],223 MOV
  866. ES:[111],227 MOV ES:[112],226, etc. Runs of transparent bytes and the line
  867. wrap are encoded in the index to each MOV instruction. To display a bitmap
  868. you simply call it! This is arguably the fastest possible way to display a
  869. bitmap on the PC, and amazingly enough, it doesn't result in huge chunks of
  870. compiled code. See CTRANS.ZIP, and Dave's Bitmap Compiler in LIB 11 if you're
  871. interested. 
  872.  
  873. So we can compile individual frames of an animation sequence. What I want to
  874. do is add to that the capability for delta-frame compression. Delta frame
  875. compression is a method which saves only the changes between frames in a
  876. sequence. I'm thinking of a "delta-frame compiler" which would compile _all_
  877. of the frames in a sequence into a single delta frame compressed sequence.
  878. The compilation part is pretty straightforward, once you've performed the
  879. delta analysis. The part that puzzles me is frame rate control. I dare say
  880. that if I created a compiled sequence and called it would be too fast to see.
  881. So, how to control display rate in this instance? I'm leaning toward a
  882. call-back function which would be called at the end of each frame. It could
  883. simply return, or implement a delay loop. What do you think? 
  884. ...........................................................................
  885.  
  886. Fm: Jaimi 71700,1202                           # 216774 
  887. To: Mark Betz/GD SL 76605,2346 (X)             Date: 23-Sep-92  20:52:38
  888.  
  889. Mark,
  890.  
  891.   Since you're going to have to slow it down, why do it? It seems that since
  892. you want to compress the animation, what is mattering is not speed (which is
  893. limited by the speed of your bus and your VGA anyway) but size, and a
  894. compiled bitmap would take 3 times as much space as a data bitmap. Also, is
  895. it really truly faster than doing REP STOSW? If you used data, you could
  896. define a structure that held the x,y,w,h of each "frame" (in quotes because
  897. it could be just a partial frame) and also the length of time that it was
  898. supposed to be displayed before passing on to the next frame. Then a vary
  899. small routine could be written that would basically just store it to the
  900. screen, and then wait to return. all you would have to do is call it in a
  901. loop. You asked what I thought! I just didn't think it would take this much
  902. space! 
  903. ...........................................................................
  904.  
  905. Fm: Mark Betz/GD SL 76605,2346                 # 216800 
  906. To: Jaimi 71700,1202 (X)                       Date: 23-Sep-92  21:54:50
  907.  
  908. Well, three times larger is a pathological case, complex bitmap with no
  909. transparency. I think the best David got was in the neighborhood of 1.4 times
  910. the data size. It is definitely faster than a rep stosw. By several orders of
  911. magnitude. All of the data is immediate data, and there is no address
  912. calculation. The raw bus transfer rate doesn't change, but a lot of other
  913. overhead is removed. Take a look at the test programs in lib 11.
  914.  
  915. The reason for doing it is that the compiling, combined with the delta
  916. compression, should produce animations sequences which are both smaller, and
  917. much faster than they would be done the usual way. Suppose you were doing an
  918. arcade-like game, and you had a character sprite with various distinct
  919. motions: run, crouch, jump, swing, etc. Each motion could be compiled into an
  920. animation sequence. Then the entire animation process is a simple matter of
  921. calling the proper motion. Since the compiled sprites are very fast, you can
  922. use a lot of frames for very smooth and fast sprite actions.
  923. ...........................................................................
  924.  
  925. Fm: Dan R Corritore 70243,1110                 # 216826 
  926. To: Mark Betz/GD SL 76605,2346 (X)             Date: 23-Sep-92  22:57:09
  927.  
  928. I'd like to say that the delta frame compression is a great idea..Deluxe
  929. Paint Animation uses it, and I'll most likely use it too, but _only_ for
  930. pre-ordered animations. What you are saying about having a sprite which can
  931. run,crouch,jump, etc. be a compiled delta-frame-compression thingy :-) is not
  932. a good idea if you are planning on having more than one color as a background
  933. color, or having the sprite be able to walk behind masks, or having the
  934. sprite be able to walk partially off the screen(or window)..compiled sprites
  935. are basically not good for realistic applications in my eyes. On the other
  936. hand, having compiled-delta-frame-compression to be used on pre-ordered
  937. animations (an opening sequence for a game, perhaps) is a pretty neat idea. 
  938. ...........................................................................
  939.  
  940. Fm: yngvi 76703,3046                           # 216992 
  941. To: Mark Betz/GD SL 76605,2346 (X)             Date: 24-Sep-92  13:20:27
  942.  
  943. I worked on a project using delta compilation about 6-7 years ago -- we did
  944. traffic accident simulations to support expert witnesses in trial testimony.
  945. Our system was pretty primitive -- we were constrained by existing technology
  946. among other considerations.  (the animation was all CGA).  We did manage to
  947. get up to about 10 sec of animation into a 300K system.  I wrote an article
  948. about it for Computer Language magazine at that time.
  949.  
  950.   It's been awhile, but I think the timing was controlled during the delta
  951. calculations.  The frame rate was one of the set up parameters.  The playback
  952. program could run at either the 'real' rate or several faster or slower rates. 
  953. This turned out to be useful for the experts, since they could speed up, slow
  954. down, step thru or even freeze the action.
  955.  
  956.    Steve
  957. ...........................................................................
  958.  
  959. Fm: Bob Provencher 71621,2632                  # 216807 
  960. To: Mark Betz/GD SL 76605,2346 (X)             Date: 23-Sep-92  22:32:10
  961.  
  962. Hi Mark,
  963.  
  964.        That sounds like a good idea to me.  I can think of a few ways to
  965. handle the frame rate.  At the end of each frame insert an instruction that
  966. loads the address of the start of the next frame into a register and
  967. returns.  Something like this in pseudo assembler (remember I don't know
  968. assembler that well)
  969.  
  970.        MOV     ES:[110],223
  971.        MOV     AX,[IP+?]       ; whatever the correct offset would be to
  972.                                ; the start of the next frame...
  973.        RET
  974.        MOV     ES:[0],86       ; here
  975.        ...
  976.        MOV     AX,0            ; last frame
  977.  
  978. Then in the timer interrupt handler you could do something like this:
  979.  
  980.        MOV     AX,[NEXTFRAME]  ;
  981.        ???                     ; test here for zero
  982.        ???                     ;
  983.        CALL    AX              ; if there is such an instruction
  984.        MOV     [NEXTFRAME],AX  ; save the next frame's start
  985.        IRET                    ; return
  986.  
  987. If you implemented a callback function at the end of each frame it might be
  988. kind of difficult to control the delay loop to have the same delay for each
  989. frame.  This way you're guaranteed to have frames equally spaced.  Does this
  990. make sense?
  991. Bob
  992. ...........................................................................
  993.  
  994. Fm: Mark Betz/GD SL 76605,2346                 # 217074 
  995. To: Bob Provencher 71621,2632 (X)              Date: 24-Sep-92  18:15:37
  996.  
  997. Sort of, yes. However, even spacing might not always be desireable. Consider
  998. an action, such as jumping: various individual motions might require
  999. different timings to make the sequence look realistic. I was thinking that
  1000. you could use a callback function, and then point to a table of delays right
  1001. before calling the animation. Everytime the callback function was executed it
  1002. would load the next delay value and wait that long before executing the next
  1003. frame. This would give quite a bit of flexibility over frame timing. What do
  1004. you think? 
  1005.  
  1006. ___________________________ Subj: Game Generators ___________________________
  1007.  
  1008. Fm: Fire Bird 71045,2014                       # 198831 
  1009. To: all                                        Date: 11-Aug-92  20:58:43
  1010.  
  1011. Are there any game generation systems out there? I know Sierra made their
  1012. own, and so did a lot of other gamming companies.
  1013.  
  1014. I think it would be fun to design a game and chalenge everbody.
  1015.  
  1016. Eg one with two different parts.
  1017.  
  1018.         Game design (create screens, dialog, maps, sound, etc)
  1019.                 produces data files
  1020.  
  1021.         Game runtime (requires data)
  1022.                 produces fun
  1023.  
  1024. I wonder...Hmmm...shared gaming...Multiuser...compuserve messages...
  1025. ...........................................................................
  1026.  
  1027. Fm: Serge Mathieu 71035,2771                   # 198907 
  1028. To: Fire Bird 71045,2014                       Date: 11-Aug-92  22:34:38
  1029.  
  1030. Sierra hired a programmer for a full year just to program a game interpreter
  1031. a couple of years ago. This is NOT a simple task; you have to design
  1032. everything so your generator won't become obsolete if you want to add
  1033. features like AI, OOP, automatic sprite handling, garbage collection, events,
  1034. etc... 
  1035.  
  1036. Serge Mathieu
  1037. ...........................................................................
  1038.  
  1039. Fm: Mark Betz/GD SL 76605,2346                 # 199188 
  1040. To: Fire Bird 71045,2014                       Date: 12-Aug-92  18:40:32
  1041.  
  1042. Hi, Carl. Welcome! There are certainly some game construction engines
  1043. available. In LIB 2 here you'll find both the AGT Adventure Game construction
  1044. kit, and DCGames CRPG construction kit. I've heard lately that the new
  1045. version of DCG is really superb. Also, on the commercial end, Interplay
  1046. released the Bard's Tale Construction Set. I don't know much about it. It
  1047. would be interesting to design a game generation system. Most of us here
  1048. approach that only in that we design many tools for our own use, such as
  1049. frame editors, font editors, palette utilities, etc.
  1050.  
  1051.  
  1052.                                                         --Mark
  1053.  
  1054. __________________________ Subj: Shrinking Sprites __________________________
  1055.  
  1056. Fm: John Dlugosz [ViewPoint] 70007,4657        # 330492 
  1057. To: Mark Hula 100047,110 (X)                   Date: 10-Apr-93  12:28:07
  1058.  
  1059. That is a complex subject.  One way is to remove extra rows and cols. Upon
  1060. removing, either toss out or merge it with an adjecent row, depending on the
  1061. nature of the image.  Another way is to take a clump of pixels and average
  1062. them together.  Easy to reduce to 1/n where n is an integer, but harder to
  1063. reduce by an arbitrary amount.  Also this gives you an all new palette.
  1064.  
  1065. <<My question is how do I work out with column or row to remove inorder to
  1066. shrink the object>> Same way you draw lines and decide when to "jag". 
  1067. Picture a rectangle MxN where M is the old number of rows and N is the new. 
  1068. Look at a diagonal line drawn in that rectangle.  It it gives a plot of which
  1069. rows to keep!  Just take one of the rows from each "run" of a horizontal
  1070. line.  One row for each jag, IOW.
  1071.  
  1072. Rotating by 360 degrees is simple-- just a null operation.
  1073.  
  1074. --John
  1075.  
  1076.